Computer displays typically are constructed in a manner to display text and other video information in a landscape mode. There have been some displays that are constructed to display video data in portrait mode. To bridge the gap between the two modes of displays, some have built software drivers to enable a display to be rotated between landscape and portrait mode (e.g. typically 90° or 270°) and then to trigger a software switch (either automatically or under user-controlled input) in order to render the image “right-side up.”
One approach has been to provide a display driver which uses a back buffer and a front buffer. The back buffer is a memory surface which has an orientation which is natural for the hardware, while the front buffer is in the natural orientation of the display device. The back buffer is an opaque surface, which forces the graphics device interface to call through to the display driver. The graphics device interface renders the desktop to the back buffer, while the front buffer is used to satisfy the display refresh. The driver then updates the front buffer using the back buffer contents using a rotating bit block transfer function.
Conventional rotation systems have the disadvantage that an existing display driver must be replaced by a new driver to support a rotated display. Development of a full display driver which supports a rotated display requires extensive effort and validation, since the driver would need to perform graphical operations in rotated form. Furthermore, some conventional drivers rotate each graphical primitive on the fly as it is rendered into the frame buffer. This approach results in the disadvantage that the pixels of the frame buffer are stored in a rotated orientation, which compromises compatibility with most applications that only understand pixels in the traditional unrotated landscape organization. Although the organization of the pixels in the buffer remains the same, the image contents are rotated. The result is that applications and the operating system, which typically access the contents of the frame buffer, will have difficulty in interpreting the rotated format of the contents of the frame buffer. To overcome this compatibility problem, the contents of the frame buffer would have to be converted to an unrotated format before an application could access the contents.